Listening GA`s

[dschiffner]

Moin habe mal kurz ne Frage. Gibt es irgendwo ein Tutorial bzw. eine genauere Erklärung wie das mit den listening GA´s funktioniert bzw. welche GA/Werte dort aus der ETS eingetragen werden.
Bzw wann trage ich mehrer Werte ein.

Das < heist Wert beim Start abfragen richtig ?

Type switch : demoSwitch "Light" [ ga="3/0/4+<3/0/5" ]
Type rollershutter : demoRollershutter "Shade" [ upDown="4/3/50+4/3/51", stopMove="4/3/52+4/3/53", position="4/3/54+<4/3/55" ]
Type contact : demoContact "Door" [ ga="1.019:<5/1/2" ]
Type number : demoTemperature "Temperature" [ ga="9.001:<5/0/0" ]
Type dimmer : demoDimmer "Dimmer" [ switch="5/0/0+<5/0/1", position="5/0/2+<5/0/3", increaseDecrease="5/0/4" ]
Type string : demoString "Message" [ ga="5/3/1" ]
Type datetime : demoDatetime "Alarm" [ ga="5/5/42" ]

Gruß Dennis

[udo1toni]

Grundsätzlich kann man bei knx jedem KO (KommunikationsObjekt) mehrere GA (GruppenAdressen) hinterlegen. Dabei gilt, dass auch, wenn das KO schreibend auf den Bus zugreifen darf (S-Flag gesetzt) Schreibbefehle ausschließlich auf die erste eingetragene GA erfolgen. Deshalb spricht man bei allen anderen GA von listening GA. Die erste eingetragene GA wird auch gerne Haupt GA genannt.

In openHAB wird das genauso abgeblidet, man kann einem KO (ein Parameter eines Channels) mehrere GA zuweisen (durch + getrennt), ein sendCommand() wird aber immer ausschließlich auf die erste GA wirken, somit sind alle GA nach einem plus (+) listening GA.

Weiterhin besteht die Möglichkeit, KO lesbar zu definieren, ein Busteilnehmer sendet einen Read Request an eine GA und der Busteilnehmer, in dessen mit der GA verknüpftem KO das L-Flag gesetzt ist, beantwortet den Read Request. Hier lauern gleich mehrere Konfigurationsfallen:

1. Es darf maximal ein KO pro GA das L-Flag gesetzt haben, sonst antworten mehrere Busteilnehmer (Busfehler oder gar Chaos).
2. Wenn auf dem KO mit gesetztem L-Flag mehrere GA definiert sind, wird der Busteilnehmer auf jeden Read Request einer der gesetzten GA antworten, aber immer(!) mit der ersten gesetzten GA. Wenn man also in einem KO die GA 1/1/1,1/1/2 stehen hat und ein Read Request auf 1/1/2 herein kommt, sendet der Busteilnehmer seine Response auf 1/1/1

In openHAB markiert man die GA, von denen der Status bei Systemstart gelesen werden soll mit einem <.
Üblicherweise programmiert man seine knx Komponenten so, dass jeder Aktor eine GA im KO für den Schaltbefehl hat und eine andere GA im KO für den Status des Schaltkanals.
Im Taster ist dann die erste GA und die zweite GA hinterlegt. Schaltet man den Aktor, sendet der Aktor ein Statusupdate auf der zweiten GA und der Schalter weiß, welchen Zustand der Aktor hat.
Auf die gleiche Weise konfiguriert man openHAB.

Nun könnte man auf die Idee kommen, dass der Schaltbefehl doch ohnehin mit gehört wird. Aber was passiert, wenn der Aktor (eventuell sogar mehrere) listening GA auf dem Schaltbefehl KO hat (z.B. für Zentral Aus)? Was passiert, wenn der Aktor einer Szene zugeordnet ist? Was ist mit Zwangsschaltungen? In allen Fällen könnte openHAB (und auch ein Wandtaster) keine zuverlässige Aussage über den aktuellen Schaltzustand treffen.
Wandtaster sollen bei Einflächenbedienung den Zustand des Aktors toggeln. Da knx keinen Toggle Befehl kennt, muss der Taster wissen, welchen Zustand der Aktor hat. Für openHAB steht dies ohnehin außer Frage.

Die Konfiguration jedes knx Channels (eigentlich gilt das im großen und Ganzen für alle Channel aller Addons) setzt sich also aus dem Befehl in Senderichtung und dem Status in Empfangsrichtung zusammen. Für Schaltkanäle gibt es entsprechend immer zwei GA, für Dimmer gibt es (auf openHAB Seite) drei GA, nämlich den Ein/Aus Befehl sowie Absolutwert Setzen und Absolutwert Status. Man möchte für einen Dimmer wissen, wie hell der Dimmer eingestellt ist, daraus ergibt sich auch der Zustand Ein/Aus. Wenn man hier mehr GA angibt, führt das nur zu Chaos. Auch increaseDecrease ist mehr hinderlich als hilfreich.
Für Rollladen gibt es vier GA, nämlich den Befehl UP/DOWN, den Befehl STEP (der hier als Stop Befehl verwendet wird) und Absolutposition setzen sowie Absolutposition Status.
Für alle Items, die mit knx verlinkt sind, sollte grundsätzlich autoupdate="false" gesetzt werden, denn man möchte den echten Status angezeigt bekommen, nicht einen, den openHAB sich ausgedacht hat. Wo immer ein Addon den echten Status zurück meldet, ist diese Option sinnvoll.